При внутренней разработке довольно часто бизнес-требования накапливаются, а их приоритетность для компании меняется чуть ли не ежедневно. Хотелок бизнеса, понятное дело, много и они прирастают довольно хаотично и в большом объеме.
Есть довольно большой риск того, что после релиза окажется, что реализованный пакет бизнес-требований окажется низкоприоритетен для достижения основных целей компании - максимизации прибыли и повышения качества обучения клиентов.
Что делаем мы? На стадии работы аналитика с представителем бизнеса происходит выявление системных конфликтов и узких мест (TOC) и в результате применения принципов Lean формируем пакет минимально необходимых требований для ближайших релизов (обычно на ближайший месяц).
Автоматизация бизнес-процессов компании получается точечной, но она позволяет более эффективно использовать ресурсы ит отдела и оптимизировать работу сотрудников компании.
Я хочу поделиться с коллегами тем как мы пришли к этому процессу работы с требованиями и что получили после его внедрения, поделиться своим опытом на примере некоторых проектов.
Докладчик Лузгарев Николай
https://www.facebook.com/stmirageowl/
На данный момент я занимаюсь направлением, связанным с автоматизацией и диспетчеризацией производства. Я бы хотел рассказать в своём докладе о том, каким образом формируются и собираются требования на некоторых моих проектах в этом направлении. Основной фокус доклада будет направлен на то, что во многих подобных системах, участники процесса не заинтересованы в том, чтобы система работала так как задумана. Мотивация работников зачастую противоречит той логике, которая заложена в бизнес процессы. Работники отлынивают от работы, обманывают датчики, используют оборудование в своих целях, нарушают режимы работы. Расскажу о системах диспетчеризации оборудования, как единственном источнике пользовательских историй, который не искажает информацию. Отмечу, как проходит инициация команды, как аналитик взаимодействует со стороной IT продакшена и стороной реального производства, являясь связующим звеном.
Вопросы:
Проекты, в которых пользователь изначально настроен действовать вопреки бизнес-правилам
Инициация команды
Сбор требований в условиях, когда информация сознательно искажается
Противоречия интересов пользователей
Мы очень часто говорим о том какими компетенциями должен обладать аналитик , и что такое аналитик 80-ого уровня :-)
Однака эффективность работы бизнес и системного аналитика, архитектора , руководителя проекта ... (всех проще говоря) зависит не только, и не столько от компетенции отдельной роли но и от уровня зрелости всех остальных процессов.
В рамках круглого стола предлагаем обсуждение какие бывают и как влияют на результат:
Приглашаем всех экспертов :-)
Расскажу об организации рабочего времени сотрудников в крупных компаниях (в компаниях - интеграторах и компаниях - клиентах ) в период кризисов. Рассмотрим два направления: внутренняя организация рабочего времени (внутреннее обучение) и внешняя организация рабочего времени (смартстаффинг). Обсудим как извлечь пользу рядовым сотрудникам и организациям во время кризиса.
Ходят легенды о том, что бОльшая часть людей визуалы и лучше воспринимают информацию, когда она представлена в визуальной форме. А ещё хотят легенды о том, что научиться рисовать очень сложно.. Знающие люди говорят, что визуализировать и рисовать – это немного разные вещи. В течение этого короткого воркшопа участники узнают, зачем и когда можно использовать визуализацию, увидят, что этому можно легко научиться и потренируются это делать прямо на воркшопе. Этот воркшоп будет полезен как начинающим, так и продолжающим бизнес-аналитикам.. а вообще, он будет полезен всем, кто ещё не использует визуализацию в своей работе в полной мере. Кстати, теории на нем почти не будет. А вот практики...
В докладе хочу поделиться своим недавним опытом на одном проекте, в котором я был сначала аналитиком и проектировщиком, потом взял на себя роль менеджера по продукту и продюссера выпуска продукта.
Продукт был выпущен, но в какой-то момент перестал быть продуктом, а стал, фактически, проектом внутренней автоматизации. Менеджер по продукту здесь перестал быть нужен, и фактически сейчас я опять выполняю роль аналитика и владельца бэклога.
В докладе хочу расказать - как происходят метаморфозы проекта, в какой момент проекту нужен аналитик. а в какой - менеджер продукта, когда они нужны оба и как они делят ответственность, и как выжить во всей этой катавасии.
В нестабильные и кризисные времена руководству компании как никогда важно знать возможности своих сотрудников, их потенциал, вектор развития.
А фраза «экономика должна быть экономной» приобретает больше смысла и становится лозунгом многих директоров.
Каждый руководитель задавался следующими вопросами:
· Что можно сделать, чтобы снизить текучку кадров и сопутствующие расходы?
· Как экономить время дорогих сотрудников на проведение собеседований?
· Как оптимизировать расходы на обучение и тратиться только на те курсы, которые действительно нужны сотруднику?
· Как понять, что сотрудник находится на своём месте и занимается тем, что ему интересно?
· Как понять, кто в случае форс-мажора сможет заменить уникального специалиста?
Наша компания столкнулась с подобными проблемами около 5 лет назад в период роста и повышения эффективности работы. И решение этих проблем было найдено во внедрении четких и прозрачных процессов оценки персонала, выполняющейся на регулярной основе.
Внедрение оценки компетенций оказалось очень непростой задачей, которая решалась нами в несколько этапов.
Для начала нам достаточно было анкет в MS Excel для выявления общих компетенций сотрудников, но в дальнейшем при увлечении количества сотрудников, при специализации анкет под различные роли сотрудников и их позиции в компании, стало понятно, что без полноценной автоматизации оценка компетенций становится очень сложным и дорогим процессом.
В докладе я расскажу об опыте разработки анкет оценки компетенций аналитиков, проведения подобных оценок, проблемах и сложностях, с которыми мы столкнулись и к каким результатам пришли.